一、前情提要：接上 Odoo，資料應用開始

在昨天的 Day12，我們已經成功讓 Make 和 Odoo 串上線，透過 API 金鑰建立起 「Make 可以查 Odoo」 的通道。
今天的任務，是把這條通道實際運用起來：

當客戶傳訊息「查訂單」給 LINE 官方帳號，系統能主動回覆歷史銷售單列表，並以 quickReply 按鈕形式呈現！

這樣做的好處包括：

• ✅ 引導式選擇：避免客戶亂輸入或格式錯誤，減少查無資料的狀況
• ✅ 自動化處理：客服無需手動查單，系統直接回應
• ✅ 更佳體驗：採用 LINE 原生 quickReply 互動，介面簡單、直覺、即時

只要按一個按鈕，就能查詢特定訂單內容，讓客服流程更有效率！

二、使用者情境：客戶查詢歷史訂單

讓我們延續昨天的實際場景：

客戶在 LINE 輸入：「我要查訂單」  
Make 判斷這是舊客戶後 → 到 Odoo 找出他過去的銷售單  
把訂單列表（例如 SO2025-0001）使用 quickReply 按鈕，顯示在 LINE 上  

這麼一來，客戶就可以直接點選想查詢的訂單，不需要自己手動輸入單號，也不會因為打錯字、漏打前綴，導致系統找不到資料。

更重要的是，這個步驟只是一個開端：
當客戶點下某張訂單後，我們還會進一步查詢訂單明細（Day14登場）

今天的主角，就是讓這些訂單號碼出現在 LINE 上，還能讓客戶一指點選！

三、實際操作：從 Odoo 到 quickReply 的完整流程

🔧 步驟 1：新增 Odoo 模組的 Make an API Call 並設定參數

以下提供我的設定作為範例，大家可以根據自己的需求去做調整。

Search Parameters：
{"fields": ["name", "partner_id", "amount_total", "invoice_status"],"order": "create_date desc","limit":80}

Parameters：
[[["partner_id", "=", "{{6.`1`}}"], ["create_date", ">=", "{{formatDate(addMonths(now; -3); "YYYY-MM-DD")}}"],
 "|",["state", "=", "sale"],["state", "=", "sent"]]]

Parameters 這段設定的邏輯是：
我希望在 Odoo 中查詢 partner_id 等於 「Search Rows 查詢到的公司」 （也就是 Google Sheets 中的 B 欄位），並且只取三個月內建立的銷售訂單。 訂單狀態 必須是 「銷售訂單（sale）」或「報價單送出（sent）」。

🔧 步驟 2：新增 Router 分流

Odoo 查詢結果可能有兩種情況：

1. 有查到單據
2. 沒有查到單據

因此，我們加入一個 Router 來將結果分流，方便後續針對不同情況做處理。

🔧 步驟 3：沒單據的路線設定－篩選

第一條路線專門處理「沒有查到單據」的情況。
篩選條件設定為 Odoo Make an API Call 的 Output Body 數量等於 0，代表查詢結果為空。

🔧 步驟 4：沒單據的路線設定－回傳

當沒有查到任何單據時，我們讓 LINE 回傳訊息給客戶：「沒有查到單據」。
這裡我新增了一個 LINE Send a Reply Message 模組，並設定 Reply Token。

Reply Token 是 LINE 平台在使用者傳送訊息時，臨時提供的一次性回覆憑證，必須在 1 分鐘內 使用，才能直接回覆該則訊息。

💡 小提醒：
1.Reply Token 只能用一次，用過就失效
2.若要在之後回覆，必須改用 Push Message

🔧 步驟 5：有單據的路線設定

第二條路線用來處理「查到單據」的情況。
篩選條件改為 Odoo Make an API Call 的 Output Body 數量 不等於 0，表示確實有訂單資料，接著進行 quickReply 按鈕的呈現。

🔧 步驟 6：使用 Reply Token 發送 quickReply

最後，新增一個 LINE 的 Make an API Call 模組，將查詢結果轉換為 quickReply 按鈕格式回傳給客戶。
在設定中需要填入 URL、Method 和 Body。

Body：
{"replyToken":"{{3.events[].replyToken}}","messages":[{"type":"text","text":"請確認單據：","quickReply":{"items":[{"type":"action","action":{"type":"message","label":"{{10.body[1].name}}","text":"單據：{{10.body[1].name}}"}},{"type":"action","action":{"type":"message","label":"{{10.body[2].name}}","text":"單據：{{10.body[2].name}}"}},{"type":"action","action":{"type":"message","label":"{{10.body[3].name}}","text":"單據：{{10.body[3].name}}"}},{"type":"action","action":{"type":"message","label":"{{10.body[4].name}}","text":"單據：{{10.body[4].name}}"}},{"type":"action","action":{"type":"message","label":"{{10.body[5].name}}","text":"單據：{{10.body[5].name}}"}}]}}]}

Body 必須遵循 LINE 官方 quickReply API 的固定格式（官方文件）。

其中 label 是按鈕上顯示的名稱，而 text 則是在客戶點擊後回傳給系統的訊息內容。

到這裡，我們就完成了從 Odoo查詢 → 判斷有無訂單 → 回傳 LINE quickReply 按鈕 的整個流程。

四、測試成果：真的可以互動了！

現在來測試看看：

1. 打開 LINE，傳送訊息
2. Make 自動查找歷史銷售單
3. 若無歷史銷售訂單，客戶就會收到 「您好，目前查無訂單。」 的訊息
   
4. 若有歷史銷售訂單，客戶就會收到一排 quickReply 按鈕
   
5. 點選其中一筆，Day14 將接著查詢詳細內容！

這就是今天要實作的核心流程 🎯

五、結語：互動式客服的第一步

今天，我們把 Make × Odoo × LINE 真正串了起來，完成了第一個能「主動互動」的客服功能：

• 📦 自動從 Odoo 撈取歷史銷售單
• 🖱 轉換成 LINE quickReply 按鈕，讓客戶一鍵查單
• 🚫 避免輸入錯誤或格式不符造成的查無資料

這不僅減輕了客服的查單負擔，也提升了客戶體驗，讓溝通變得即時又精準。

而這一切，只是互動式客服的開端！

明天的 Day14，我們將進一步處理 客戶點選某張訂單後，系統自動回傳該單的詳細明細，讓查詢功能從「有單號」進化到「有完整內容」。

互動式客服，正式啟動 🚀
我們明天見 👋

🎁 小彩蛋

如果你今天眼睛夠尖，應該有發現我在送給 LINE API 的 quickReply 格式，是 「寫死」 的。
對，你沒看錯——它完全不管我到底有幾張訂單，就像餐廳菜單永遠只印三道菜一樣，剩下的想吃？抱歉，沒有！

但現實是，我們的自動化流程根本不知道會有幾張訂單，有時 1 張、有時 5 張、有時直接 20 張，固定格式根本不夠用。

那怎麼辦？
放心，我們不會真的讓客戶只能點「假菜單」。
我已經偷偷埋下伏筆——之後會請 AI 當「菜單小弟」，幫我們自動把 quickReply 按鈕生出來，訂單多寡隨便你，全部自動搞定。

所以…大家就等著看 AI 端菜上桌吧 😏